By Jay Shirley

Software is like any other product that is depended upon for doing any particular function. Software, vehicles and computer hardware are all simply tools intended for a particular audience; audiences that tend to become polar, enthusiastic and fanatical. Whether it is the car tuning crowd, the overclockers or the Perl hackers, they share the same thing in common: being devoted to something.

This devotion drives a great number of innovations, and this is where Software really stands out. Particularly amongst the Open Source crowd, where Software is bound with something even more polarizing: Personality

The merging of software and personality is both a blessing and a curse. People are seldom more motivated than when working with something that feels alive; but to attack or criticize is, by definition, personal.

The people who are the most knowledgeable to defend, market, recommend (or even attack) are the ones already entrenched. They are part of the personality mesh, and as such it is exceedingly difficult to try to promote and defend a software product without going into the years of positive experiences one has shared with the product.

This article is no different. I love Catalyst and have used it for years. I will, however, attempt to back up my passion with articles of reason and rational points rather than espouse virtues that are little more than anecdotal.

To get started down this path, I think it is important to properly frame Catalyst in scope. On its own, it doesn't do much. It certainly doesn't do much well, but Catalyst by itself is really little more than a web server; it is a request handler and dispatcher and sends the response to the client.

By itself, it fails to talk to a database or handle sessions. It won't even authenticate a user. It has no template system, and no caching. So why does Catalyst have a fanatical fanbase and successful sites with it?

Quite simply, it's the CPAN.

The Catalyst philosophy is populist, not dictatorial. A belief that tools should be built to do a specific feature or function, but not require usage of any given tool; granting flexibility to a developer to solve problems the Catalyst community has not thought of how to solve.

Catalyst doesn't require you to use Template Toolkit or Mason. It doesn't push DBIx::Class as The One True ORM. It lets you pick. It trusts that you are a software developer and you are solving a problem. Catalyst just makes it easy to make your decision, and integrate that solution and start working. Between helper scripts and thin model adaptors (Catalyst::Model::Adaptor), there is virtually no hassle in integrating any CPAN module or custom code directly into your applications. The side-effect of the "trust the user" philosophy, aside from a fantastic framework, is that it is quite simply just that: a framework. It operates and evolves on the principles of synergy alone, striving to make the whole greater than the sum of its parts. A simple goal of striving to make a developers life easier, more productive and deliver higher quality results.

The results are easily quantifiable. Software development, at its core, is about solving a specific and well-defined problem. The more advanced the software is (in evolutionary, organic growth), the tasks at hand are solved more efficiently, properly and faster. The most significant improvements in development speed and quality come in the form of frameworks and libraries that have been peer reviewed, tested, poked and approved by the fanatical masses.

This lowers the barrier of entry to solve problems, and in general increases the supply of developers to meet the seemingly inelastic demand of problems that need solving. In effect, there is a framework for everybody, from the novice tinkerer who simply has an itch to scratch to the mathematically minded engineers that operate on puritan principles. Catalyst strives to match the pace of the whole spectrum, which is significant work. It makes the upfront learning curve a bit steeper than it could be. Looking historically over the documentation and tutorials, this will change and the learning curve will be greatly reduced.

The important thing that every developer, whether extending Catalyst or using just the minimums, Catalyst is simply a tool. Tools in the software sense are different than in the tangible world, they can change shape and function. They can easily be used incorrectly, or adapted and accidentally solve an unexpected problem.

Catalyst developers understand this, and the goal is to simply develop a robust foundation, particularly in the web application space, to solve problems. How those problems are solved is left up to the developer, though. The Catalyst community, just as the Perl or any other community, has suggestions and opinions but ultimately the responsibility lies on the developer. A core tenant of the Catalyst (and the greater Perl philosophy) is to trust that the developer knows enough to solve the problem. The tool should never impose philosophical beliefs; imagine if a hammer would only hammer specific nails, what problems could be solved then?

This lack of capability, or rather tools being an obstacle rather than an aid, was what drove Catalyst to grow and evolve. Taking original concepts from other frameworks (like Maypole) and extending those ideas in an open minded fashion, and also to use more modern development practices and factor out common code to be shared outside of Catalyst.

When Catalyst hit version 5.5 several years ago, the codebase was solid enough to call mature. It was grown up, but not done growing. At this point, the mature development cycle began and rather than a rapidly growing and changing framework, a stable and robust framework was in existence. This started a chain of high-quality (and some high-traffic) sites that were built on Catalyst. There was much rejoicing.

There are a lot of websites running on Catalyst, for a full list please view the Catalyst wiki.

Jay Shirley is a Catalyst evangelist, an EPO founding member and just another Perl hacker. He's launched and managed several large scale projects on Catalyst, as well. He is the co-founder of Cold Hard Code, LLC, a company set up to use Perl and open source technologies to spawn quality websites.

by Mark Stosberg

In 2006, the arena of Perl web frameworks pitted the heavyweight Catalyst against the lightweight CGI::Application. Since then Perl’s framework options have continued to evolve. While both CGI::Application and Catalyst remain popular, several new options have appeared lately. Here’s a quick rundown.

Titanium provides CGI::Application and a bundle of recommended plugins with unified documentation and easier installation. Because the underlying components are the same solid ones that have already been in use, it’s safe and stable to use, despite the new name. Future plans include providing a download package which bundles the dependency chain, for even easier installation.

HTTP::Engine is Moose-based evolution of the HTTP request object we saw in Catalyst, along with the abstractions to run web apps on various server backends. In short, it focuses on the HTTP parts of the web framework stack. On top of that you can build a complete framework in whatever style you want.

Mojo and Mojolicious represent a project lead by Sebastian Riedel, one of the original Catalyst contributors. Mojo is distictive for having no dependencies beyond core Perl. Mojo provides the same kind of low-level HTTP components as HTTP::Engine, while Mojolicious represents one possible complete framework built on top of it. Mojolicious’ distictive feature is a new dispatching design in the spirit of Ruby-on-Rails “Routes”. I have more in-depth review of Mojo.

Some trends I see:

• Shared infrastructure — While Perl frameworks continue to compete at a high level, we continue to collaborate on shared utility modules. Projects like HTTP::FillInForm and Data::FormValidator get used by several frameworks, not re-invented.
• CGI.pm must die — While we share some things, HTTP::Engine, Catalyst and Mojo have all invented their own HTTP request object, replacing the function of CGI.pm. Clearly there is an interest is moving beyond this old standby, which crams 172 subroutines into the CGI name space. (CGI::Application remains neutral on this point, outsourcing the query object)
• Potential for convergence — A number of CGI::Application and Catalyst plugins are rather similar, but not interchangable. Because they are open source, they are usually easy to port from one framework to the other, but this is not ideal. HTTP::Engine and Mojo are both a kind of “framework for frameworks”. I see potential for projects to agree on which backend they use, while providing distinctive experiences for programmers who may want to choose a lightweight framework or a featureful one. The result could be web framework plugins which more widely useful to the Perl community.

Mark Stosberg has been using programming Perl for the web for over a decade. He is the Principal Developer at Summersault and maintains several CPAN modules including Titanium and Data::FormValidator.

The Perl Foundation has announced a Hague Grant for Jerry Gay to implement the Rakudo Perl command line interface.

The work will be to define the S19 synopsis pertaining to command-line interaction with Perl 6, and to provide a Rakudo implementation of the synopsis.

Jerry will need to document the Perl 6 command line syntax, implement its tests, create a command line parsing library for Parrot, and implement a subset of the Perl 6 command line syntax.

I couldn't be happier with this direction. I made some vain stabs at command line interaction on Rakudo long ago, but not much came of it. Having a command line interface will make it much easier for users to work with Rakudo as it progresses. Perl without being able to do filtering magic isn't very Perly, no?

Patrick Michaud also received a Hague Grant, to work on the Perl Compiler Toolkit and regexes and other internal hoohah. I'm sure it's useful, but this feeble-minded reporter's head hurt when trying to follow the details of the grant.

By Kieren Diment

Over the past couple of months, Matt Trout and I have been putting together a book proposal for the Catalyst web framework. We did this because a. we want to publish a book about Catalyst, and b. because a publisher approached us. Now that the proposal is in, the editorial board are concerned that there is insufficient market.

I've looked at a bunch of statistics (mailing list size, Google hits, IRC channel size, Amazon sales rankings and more) to compare the size of Catalyst to a group of other web frameworks. Catalyst comes out at the bottom of the top of this list, in that it's the least popular of the "big" frameworks - Ruby on Rails, Django and so on. On the other hand, it's clearly an order of magnitude more popular than the small frameworks (Pylons, Turbogears and the like). We also know that Catalyst runs some pretty big streaming media websites, including some that we're a bit embarrassed (NSFW) to talk about. Catalyst is also rumoured to be running the BBC iPlayer.

Our publisher now has cold feet, and wants to collect more data on the size of the market before they give us the go-ahead, so if you use Catalyst, please answer a short survey for us . My aim is 100 responses (10% of mailing list subscribers).

The questions are as follows:

• What country are you in?
• How many people are on your team?
• How many of those people are writing code with Catalyst? If there are non Catalyst coders on your team, how many of the whole team would you like to be writing Catalyst code?
• How many people using Catalyst on your team are subscribers to the Catalyst mailing list?
• How many people writing Catalyst code on your team use the #catalyst IRC channel on irc.perl.org?
• What do you see as potential for growth of Catalyst in your organisation? How many people do you think will be using Catalyst in your organisation in 12 months? In 2 years?

Please email your answers to kdiment@uow.edu.au.

Kieren Diment is a Researcher at the University of Wollongong in Australia. He uses Perl and Catalyst for the social science research that he does.

The Parrot folks announced that the BBC was now on its advisory board, and it makes me happy to see. It's good to have big players in the Perl world like ActiveState join the advisory board, but I think it will mean much more to the outside world to see organizations outside of the software industry involved.

Thanks to all at the Parrot Foundation for what I'm sure took untold hours of discussion, red tape and finagling.

The mighty Tim Bunce has added yet more cool features in 2.07. Brief summary:

• Runs on Windows
• You can now turn off statement-level profiling and just have subroutine-level profiling, for speed's sake
• Tracks recursion more accurately
• Subroutine calls made within string evals are now shown in reports.

Check the full change log for all the details.

Can we just all please buy Tim a beer for all his work on Devel::NYTProf, and Adam Kaplan for starting it? NYTProf is fantastic.

By Ricardo Signes

At the Pittsburgh Perl Workshop this year, I gave a lightning talk about Dist::Zilla, the system I am increasingly using to manage my CPAN distributions. I'm using it instead of writing a Makefile.PL, but it doesn't do the same thing as Module::Build or ExtUtils::MakeMaker. I'm using it instead of running module-starter, but it doesn't do the same things as Module::Starter. I've had some people say, "So should I stop using X and use Dist::Zilla instead?" The answer is complicated.

(Well, actually, for now the answer is simple: probably not. Dist::Zilla is a lot of fun and I really, really appreciate the amount of work it saves me, but it's really young, underbaked, and probably full of bugs that I haven't noticed yet. Still, the adventurous may enjoy it.)

The idea behind Dist::Zilla is that once you've configured it, all you need to do to build well-packaged CPAN distributions is write code and documentation. If you're thinking, "but that's what I've been doing anyway!" then first consider this: If you are writing =head1 NAME\n\nMyModule - awesome module by me then you are not just writing code and documentation. If you are adding a license to every file, again, you are not just writing code and documentation.

If you use, say, Module::Starter to get all this written for you, then you're safe from writing that boilerplate stuff. Unfortunately, if you need to change the license, or you want to add a 'BUGTRACKER' section to every module, Module::Starter can't help you. It creates a bunch of files and then its job is done. It never, ever looks at your module-started distribution and fixes up things. This also means that if you realize that your templates have failed to include use strict for your last three module-started distributions, you have to fix them by hand. The same goes for the stock templates, which until recently didn't include a license declaration in the Makefile.PL.

With Dist::Zilla this content is not created at startup. It is not stored in your repository. Instead, the files in your repo are just the code, documentation, and the Dist::Zilla configuration. When you run dzil build, your files are rebuilt every time, adding all the boilerplate content from your current setup. If you want to change the license everywhere, you change one line. If you want to start adding a VERSION header, you tweak the Pod::Weaver plugin's configuration.

So, there does exist a dzil new command for starting a new distribution. All it really does, though, is make a directory (maybe) and add a stock configuration file. Why would it add anything else? If you want any code, you would only be writing the actual code needed, not any boilerplate, so adding anything would be foolish.

There's also dzil release, which goes beyond what Module::Starter (and its competitors) do and into the realm of ShipIt or Module::Release. I'm hoping I can integrate with or steal from one of those sort of tools. Right now, it exists, but all it does is build a dist and upload it. In the future, it will have at least two more kinds of plugins to make the release phase more useful: VCS (so it can check in and tag releases) and changelog management. It has a changelog thing now, but it stinks and isn't very useful. In the future, you won't need to edit a changelog. It will be able to read changes out of your commits, or you will just tell it to record a changelog entry. Then the Changes file can be generated as needed.

For now, I am manually editing my Changes file.

So, eventually Dist::Zilla could obsolete Module::Starter for people who like what Dist::Zilla does. Then again, people might still want to have starter templates that add minimal boilerplate for using certain frameworks. We'll see what happens.

Ricardo Signes was thrust into the job market with only a rudimentary humanities education, and was forced to learn to fend for himself. He is now a full-time Perl programmer, maintainer of the Perl Email Project, and frequent contributor to the CPAN.

Infoworld blogger Neil McAllister referred to Perl 6 as having "graduated to vaporware", and chromatic dissented. McAllester prints a lot of chromatic's letter and adds his own commentary, and it's a good read.

I'm glad chromatic wrote it, and McAllister ran the article, but the fact still stands that Perl 6 is vapor enough for most organizations wanting to do anything useful. The fact is that most organizations and users are going to wait for Rakudo Perl 1.0, or maybe Rakudo Perl 1.0 beta 1, before they start sniffing at it.

I wonder how we can merge these two concerns. How can we let people know about the Perl 6 that is usable here and now, such as the November wiki package written in Perl 6, and the features that people can use today and rely on not changing, while still acknowledging that Perl 6 isn't at the state that people will want to count on?

Does there need to be Rakudo Perl Early Adopter Edition, for example? I understand that any given Rakudo build could be Early Adopter Edition, but I'm talking about releasing and publicizing something that is specifically called that.

(Also, please don't bother explaining WHY Perl 6 is at the state it's in. I know why, and the people who are waiting for 1.0 don't care why. That's not the point of my question.)

As a follow-up to the Parrot Foundation's announcement of ActiveState joining the Parrot Foundation advisory board, I talked with Allison Randal about what this means for Parrot.

Andy Lester: ActiveState has joined the Parrot Foundation advisory board. Is there anyone else on this advisory board, or are they a charter member?

Allison Randal: We're in active discussions with several companies, including some that have verbally agreed to join. ActiveState is the first to complete the joining process. (I can't call them a charter member, because they weren't the first to agree to join.)

Andy: How many members do you see on this board eventually?

Allison: Membership will vary from year-to-year, but we'll aim to keep it in the range of 5-10 members.

Andy: Do members try to commit resources, as well? I'm thinking people, not dollars.

Allison: Donations of developer time or other resources aren't required for advisory board membership. I see it as a possibility in the future, but probably after the 1.0 release, when companies are working to maintain production releases of Parrot.

Andy: Is ActiveState going to try to get some developers on here, required or no?

Allison: It's not something we've discussed.

Andy: Are there any current or past Parrot developers at ActiveState?

Allison: Not as far as I know, but I don't know all the dynamic language developers currently working at ActiveState.

Andy: Are there other organizations coming up on the advisory board? In talks with anyone? Any upcoming news you can leak? It'll be just between you, me and Perlbuzz readership.

Allison: There are other organizations coming up, nothing I can leak yet, but I'll let you know when I can.

Andy: Initials? Geographic location? Anyone in Washington state?

Allison: No comment. :-)

Andy: Anything else you'd like to let us know?

Allison: Join us for the Parrot Developer Summit, November 15th and 16th in Mountain View, CA.

Andy: What will be happening there? Is it mostly a big hackathon?

Allison: We'll be kicking off the final stages to the 1.0 release. It's also a gathering point for language developers.

Andy: Thanks for the time, Allison.

As Chris Prather pointed out in Write your code like it's going on CPAN, Perl's module toolchain is getting better every day, and the support for good coding habits can help even if you don't want to distribute your code. However, starting a module distribution from scratch can be a daunting task.

I wrote Module::Starter a few years ago to make it easy to create a module distribution, but never wrote the kind of basic introduction that it needed. Now, Perl Training Australia has done just that with one of its Perl Tips, Starting a module with Module::Starter. I've already absorbed it into the Module::Starter distribution.

Module::Starter does happen to be getting a little long in the tooth, and I know that Ricardo Signes, for one, has started his own module creation magic. If Ricardo or any other authors would like to let Perlbuzz readers know about their projects, let me know.